Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000017_owner-urn-ietf _Mon Mar 10 18:21:10 1997.msg

Internet Message Format | 1997-04-01 | 8KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id SAA24921
    for urn-ietf-out; Mon, 10 Mar 1997 18:21:10 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id SAA24915
    for <[e-mail]>; Mon, 10 Mar 1997 18:21:06 -0500 (EST)
Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA09262  (mail destined for [e-mail]); Mon, 10 Mar 97 18:21:04 -0500
Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id SAA28172 for [e-mail]; Mon, 10 Mar 1997 18:21:04 -0500
Resent-From: Karen Sollins <[e-mail]>
Resent-Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
Resent-Date: 10 Mar 1997 18:21:03 -0500
Resent-To: [e-mail]
From: Daniel LaLiberte <[e-mail]>
Date: Mon, 10 Mar 1997 16:01:11 -0600 (CST)
To: "Karen R. Sollins" <[e-mail]>
Subject: [URN] semantic representation in URNs
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

You should probably remind people in each posting that you want
replies to you, if that is what you want.  I'd like to see all the
raw data somehow, however.

Karen R. Sollins writes:
 > Thus, a statement that said that no ex post facto ordering choices
 > will be supported would be one to discourage inclusion of some
 > forms of semantic expression.

Yes indeed.  In fact, I am of the opposite mind that we should declare
the structure of URNs, not that all URNs need to use that structure,
in order to support scalable (client directed) resolution.

 > CON (discouraging inclusion of semantics):
 >
 > 1) Semantics change with time.

There is a big prior question about what "semantics" means.

The semantics of how to subdivide a structured identifier do not need
to change.  Some people might call this mere syntax, but the
distinction is really arbitrary.

The *intended* semantics of how to use the components of the
identifier to resolve the identifier do not need to change even though
the human interpretation of the components may change.  URNs are
resolved by programs which do not have to worry about the changing
meaning of symbols - they're just bits.  But the symbols remain useful
to humans for memory, etc.

 >    If users become dependent on the
 > semantics being correct, resources will need to be issued new URNs
 > when the semantics change and we will have a repeat of all the issues
 > of URLs.

Not necessarily.  See the previous paragraph for one counter argument.
But this CON argument has more to do with the reorganization of the
name space than with the human interpretation of the URNs, I would hope.

Yes, new URNs would be issued for new organizations of names, but we
must already deal with multiple names for things, right?  There will
be multiple URNs for each resource - we cannot stop it.  Consider
legacy names for one.  URNs do not provide a solution for the problem
of having multiple identifiers for a single resource.  That is not
what the uniqueness property of URNs refers to - it refers to the fact
that a single URN will always only be associated with a single
resource.

Does this open the door to "all the issues of URLs"?  Yes and no.
Yes, because this is yet another way in which URNs are not
distinguishable from URLs.  No, because the uniqueness attribute,
which is not necessarily true for URLs would be declared to be true
for URNs.  (The yes and no arguments would seem to be a contradiction,
but there's more... if you want it.)

 > Remember that one form of semantics is location information,
 > and if we allow others, we will have the problems in multiple
 > dimensions.

Could you be more specific about this?  What are these multiple
dimensions?  Are you saying that any kind of semantics ties down the
identifier, as in it locates the identifier in some n-dimensional space?

 > 2) Inclusion of semantics such as in structure may imply more complex
 > information management in the UDS as described in the background
 > example above.

The structure can be optional.  Some parts of the name space need not
use any structure while other parts may use it.

A UDS need not use any structure even if the identifiers it (partly)
resolves have declared structure.  However, the structure allows
clients to talk with other UDSes that *do* use the structure.

 > 3) The hierarchy embodied on URNs reflects namespace delegation.

Delegation is not required, but hierarchy *allows* delegation.

 > To cause that to reflect other semantics as well will be very
 > difficult in the general case.

I don't understand what you are thinking here.  Please explain.

 > 4) A URN scheme is extremely unlikely to reflect all the semantics
 > that might be useful to humans.

And programs.

 > Hence human friendly schemes will be
 > needed on top anyway, and therefore by the end-to-end argument should
 > not be supported at this level as well.

What is the end-to-end argument?

My view on human friendly schemes is that, if people will want to use
them anyway, then we need to make them persistent, etc, just as URNs
would be.

 > 5) Given the problems with character sets and internationalization,
 > what is the probability of expressing semantics that would be globally
 > meaningful.

Is there really a problem here?  When would I need to refer to a document
in chinese with a chinese URN?

I don't follow character set discussions, but one of the PRO arguments
is that we *need* to use international character sets to make URNs
useful world-wide.

 > To allow for translation of semantics to be
 > internationally meaningful is certainly not part of a UDS.  Without
 > this, URNs will be meaningful to only part of the customer base at
 > best anyway.

URNs that refer to resources will be as useful as the resources
themselves, so the customer base of the resources that are constrained
to be useful only to them could probably live with similar constraints
on the identifiers.

Alternatively, multiple URNs could be used to identify the same
resource, each one meaningful to different communities.

 > PRO (don't discourage inclusion of semantics or perhaps encourage it):

I'm a devils advocate at heart, so I'll argue against some of the PRO
arguments too.

 > 1) We need to do it for some legacy systems anyway, so why not allow
 > it for all namespaces.

There is always some mapping that will be required to represent legacy
systems in our new identifier scheme, so why not require everyone to
map into numbers?  ASCII chars can be represented by their hex codes,
etc.

 > 2) If we are really suggesting using URNs instead of URLs we need
 > something human friendly now and we don't have anything else.

a. URLs can be made persistent (by similar indirection as UDSes will
provide), so we don't need URNs anyway.  URLs have sufficient human
semantics already.

b. Human friendly identifiers could become the substitute, and then
URNs become like IP numbers compared to human friendly domain names.
IP numbers are mapped to physical machines - the "real" locations.  So
are URNs really names or locations?  Or are the concepts of "name" and
"location" relative to the context in which the identifier is being
resolved?

 > 3) This is a URN issue, not a UDS issue and should not be addressed at
 > all in the UDS requirements documant.

The issue has, truefully, no necessary impact on UDSes.  But it will
encourage UDSes to make use of the semantics/structure just to be
competitive.

 > 4) The ability to support semantics does not mean that everyone has to
 > understand them.  URNs that include semantics might simply be easier
 > to remember or guess for some parts of the population, but it need not
 > imply anything about translation of URNs into other things
 > (e.g. URLs).

Right.  What's wrong with that argument?

dan